There is an increasing use of information technology (IT) by physicians as evidenced by the rapid adoption of a type of computer software, called Electronic Medical Records (EMR), to replace the paper charts in the medical office. The use of EMRs by physicians is expected to become common over the next five to ten years.
Because of the state of the art in communications between providers in the healthcare community, most physicians using an EMR must accept or receive data such as lab results, pathology results, radiology results and transcriptions via faxes or paper couriered from the hospital. The physician must then use their personnel to collect the paper fax, scan it into the EMR, and index the scanned image to a particular patient's record. Cumulatively, the process can take several minutes per fax received.
As these computer systems are adopted, there is an emerging need to receive data from hospitals in an electronic format that can be directly interfaced into the physician EMR. Data standards like ANSI's Health Level 7 (HL7) have evolved to address this need and are used by both hospital and physician-based computer systems.
However, the detailed use of the HL7 standard varies between vendors. This is a well-known problem that led to the emergence of a type of middleware called an “interface engine.” Its purpose was to translate the HL7 messages exchanged between computer systems into the native format of each. This enabled the computer systems to off-load the responsibility of managing each individual interface. Instead, each computer system would only need to manage its connection to the interface engine.
While the interface engines and EAI middleware offer advantages in enterprise settings where all computer systems are accessible via a local area network, the situation presented by EMRs is more complex.
EMRs are installed in remote physician practices, are unreachable by computer systems located in hospitals, and support the type of data that tends to be highly confidential and must be secured in the most rigorous manner.
As a result, approaches that leverage middleware technologies like HL7 interface engines must devise their own methods of delivering and securing the data. Several of the approaches currently available are: (1) establish a private network between the hospital and the EMR location, (2) use secure email to deliver the electronic data as an attachment, (3) send the electronic data via a secure website where it can be downloaded and (4) use peer-to-peer technology to enable file sharing.
Each of these approaches has the benefit of leveraging existing technology (e.g. email, web, P2P) and does accomplish the overall goal of getting electronic data from the hospital into the remote EMR. However, there are drawbacks with each approach, such as: (1) building private networks is expensive and difficult to manage as volume rises, and (2) secure email, web and P2P solutions rely on people to run the communication application, e.g., open the email, access the website or pull down the data over the P2P network.
Consequently, a need exists for allowing the electronic data to flow from system to system without involving personnel, or a special network or interface for each remote system encountered.
The preferred embodiment defined herein describes such a system that exhibits characteristics of low cost, simple operation, ease of use, reliability and stability in real-world implementations of the embodiment.